Most of you will be familiar with software development life cycles (SDLC) and probably have a favourite variant such as the Agile Model, I personally prefer a Spiral-Iterative Models and borrow extensively from Rapid Development techniques (see Steve McConnell’s book of the same name) and the more obscure “Extreme Programming Explained” by Kent Beck. But what I’m referring to in this post is within the SDLC process there’ll be a step indicating the developer produces code, and that’s what I’m referring to with “Developer Cycles”. Specifically, how efficiently can a developer produce code and test it at the module level when developing embedded code.
The most obvious metric to improve is time. So, as the logic goes, the faster a developer can build and run the debugger, the faster code can be produced. For instance, if it takes 60 seconds to build the code, 20 seconds to load and run it, and you can detect the change was successful in 30 seconds your developer cycle time is 110 seconds. Now if you can reduce the build time through automation to 20 seconds and the load time to 10 seconds you only take 60 seconds, a 45% improvement.
On the surface this should be great and if that speedup was relatively easy to do versus the length of the project, then by all means speed it up. However, that time is only part of the cycle, lets add some typical real-world parameters to our model developer. Suppose for every change the developer averages 3 cycles and spends an average of 2 minutes considering the result and designing a change. We can summarize the two cases as follows:
D = cycles * (design + build + load + debug)
D1 = 3 * (120 + 60 + 20 + 30) = 690 seconds = 11.5 minutes
D2 = 3 * (120 + 20 + 10 + 30) = 540 seconds = 9 minutes
So still an improvement but only 20% and the design and debug times will vary widely even within a single set of tasks and even more from project to project. If the code is complex causing may cycles and the debug time involves external inputs that may take hours to produce you can see the improvement will shrink to nothing. If you work on such a project then you have to compensate by:
- Spending more time in design to get it right, reduce the number of cycles
- Invest in debugging tools, perhaps simulators or add test code to the target that can exercise the feature or problem where the change occurs.
- Increase the number of targets and perform development in parallel.
So, as you can see even though the days of 10 minute compile times are for the most part behind us there are still reasons and times when the return is greater if you invest in debugging and designing code bears more fruit. Sometimes stepping off the running mill of build+load+debug, will result in a greater improvement, so be pragmatic and make sure that computer between your ears is fully engaged in the problem.
Cheers!